Dev/Versioning Format Conventions
Donate
Versioning Format Conventions for software developed under the Kicksecure hat
Versioning Format Conventions[edit]
Package Version Numbers[edit]
For individual packages (list
) developed under the Kicksecure umbrella, currently happens as follows. More or less as a custom, as a convention. Not by a finalized master plan.
1) Git commits to specific packages are being made.
2) Eventually, more git commit to specific packages are being made.
3) When the maintainer of the package feels, that substantial changes have been made, the debian/changelog version will be bumped. This is done using make deb-uachl-bumpup, which updates changelog.upstream and bumps debian/changelog version. The commit message mostly is "bumped changelog version". Let's call this state by convention the finalized version commit to ease discussing this.
4) Eventually, if someone requested it or if that version is supposed to become a Kicksecure (developers-only, testers-only or stable) release, git tags will be signed. [1]
5) Development continues. More git commits are being made. At this point, what debian/changelog version says will be false, outdated. This is non-ideal, but no one suggested how it could be done any better.
6) Back to 1).
If other substantial changes happen, such as if the generic makefile is being updated, this also deserved bumping the version number.
The format is: [epoch:]upstream_version[-debian_revision] as defined per Debian Policy, Version.
Epoch is currently set to 3 for historic reasons.
The very first upstream version is usually 0.1. Usually incremented by 0.1 (i.e. for example from 1.9 to 2.0 and so forth). Usually means, at the discretion of the package maintainer different upstream versions can be used.
Debian revision is currently always set to 1 and not in use because most changes are not packaging changes, but upstream package changes and because upstream author currently equals packager and because packages are not uploaded to Debian yet where one would just fix the packaging but leave the upstream version as is.
Kicksecure Version Numbers[edit]
The derivative-maker source code / build script references all the individual packages using git submodules. It points to specific git commits of the individual packages.
For (testers-only and stable) releases, by convention, all packages must point to finalized version commits. [2] This is useful so users can refer to package versions as dpkg reports them. (Example: dpkg -l .) Otherwise it would be version 3:0.8-1 + git~5 or something like that, which would be very unusable. This does not does not apply for developers-only releases, because those are sometimes only used for quick tests to see if the build script still runs through without any issues.
Footnotes[edit]
- ↑
To ease this, the following commands will be used.
To sign the git tag.
make git-tag-sign
To verify that the git tag can be verified and that the git hash it points to is itself a signed git commit.
make git-verify
This is not a requirement, these commands are just shortcuts.
- ↑ finalized version commit as defined above.
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2024 ENCRYPTED SUPPORT LP
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!